home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / SourceCode / MiscKit1.7.1 / MiscKitArchive.mbox / mbox / 000096_don@darth.byu.edu_Sat Jan 15 23:43 MST 1994.msg < prev    next >
Internet Message Format  |  1994-10-30  |  4KB
  1. Received: from yvax2.byu.edu by maine.et.byu.edu; Sat, 15 Jan 1994 23:43:21 -0700
  2. Return-Path: <don@darth.byu.edu>
  3. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-3 #4169)
  4.  id <01H7QA6MOSO08WWYGE@yvax.byu.edu>; Sat, 15 Jan 1994 23:43:10 MST
  5. Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF V4.3-3 #4169)
  6.  id <01H7QA6KA7DS8Y5AGS@yvax.byu.edu>; Sat, 15 Jan 1994 23:43:06 MST
  7. Received: from darth.byu.edu by alaska.et.byu.edu; Sat,
  8.  15 Jan 1994 23:42:11 -0700
  9. Received: by darth.byu.edu (NX5.67d/NX3.0M) id AA09026; Sat,
  10.  15 Jan 94 21:45:00 -0700
  11. Received: by NeXT.Mailer (1.100.RR)
  12. Received: by NeXT Mailer (1.100.RR)
  13. Date: Sat, 15 Jan 1994 21:45:00 -0700
  14. From: Don Yacktman <don@darth.byu.edu>
  15. Subject: MiscKit binaries, distributions, and release frequency
  16. To: misckit@alaska.et.byu.edu
  17. Reply-To: don@darth.byu.edu
  18. Message-Id: <9401160445.AA09026@darth.byu.edu>
  19. Content-Transfer-Encoding: 7BIT
  20. Status: R
  21.  
  22.  
  23. Hi there!
  24.  
  25. Well, now that the first release of the MiscKit is officially
  26. available, I'd like to ask a question of everybody on the
  27. MiscKit mailing list.
  28.  
  29. I think this is something we never really did discuss before:
  30. How we should handle binary distributions?  In order to answer
  31. this, I think that perhaps we should begin by discussing
  32. various options and see where that leads.
  33.  
  34. To start off the discussion, I would like to suggest that we
  35. keep the source distribution's format as it currently stands
  36. and then provide a separate binary distribution.  In doing
  37. this, I feel that the binary distribution should be a NeXT
  38. pkg file, installed via Installer.app.  This binary version
  39. should be, in my opinion, a FAT binary, compiled for whatever
  40. versions of NEXTSTEP are available at the time of release.
  41. Although the source distribution does not install the top
  42. level files of the MiscKit into LocalDeveloper, the binary
  43. distribution would have to, so that the user has copies of
  44. at least the license, license notes, history, charter, and
  45. authors files.  (Probably, I'd just put the whole top level
  46. file set somewhere in the installed Documentation folder.)
  47.  
  48. If anyone would prefer to see the source distribution as a
  49. package, too, let me know.  I'm always open to suggestions
  50. there, too.  I think putting the source in a single
  51. self-contained tar file is better for now since you get much
  52. better compression with gzip than with compress, which
  53. Installer.app uses.  Since the binaries, headers, and docs
  54. install all over the place, though, I feel a .pkg format is
  55. much simpler to use.  Of course, the target audience is
  56. developers anyway, so it probably doesn't make a lot of
  57. difference.  But I do suspect that even developers prefer
  58. mundane things like installs to be simple so as to not waste
  59. their precious time.
  60.  
  61. So, if you agree with this suggestion, or any other suggestion
  62. that crops up on the mailing list, simply send some private
  63. e-mail directly to me to avoid flooding the mailing list.  If
  64. you have a different idea, which would most likely a better
  65. idea than mine, feel free to post it to the list to foster
  66. further discussion on this.  Hopefully we can come up with a
  67. distribution method that makes everyone happy.  The main
  68. goals I see in the distributions is to make them (1) easy to
  69. install and uninstall, (2) easy to use, and (3) contain
  70. everything necessary for the user to successfully make use of
  71. the MiscKit.
  72.  
  73. Also, while we're on the topic of the format of the releases,
  74. what sort of release schedule would you prefer to see?  At
  75. the moment, I plan to do it "on demand" so that new releases
  76. happen more or less as bug fixes and new submissions become
  77. available.  I think that if releases come out any sooner than
  78. two weeks apart, people will go bonkers trying to stay up to
  79. date, so I'd say that we wouldn't do a release any _sooner_
  80. than two weeks after the most recent release.  So, does this
  81. seem to be a good policy to you?  Or would you prefer a regular
  82. release schedule (say, once a month on, say, the first Friday
  83. of the month unless there isn't anything new)?  Or use the on
  84. demand schedule, but with a larger space than two weeks
  85. in between releases?  Or something else entirely different?
  86.  
  87. Once these issues are ironed out, I plan to make a note of the
  88. group's decision in the Charter document so that anyone who
  89. grabs the MiscKit can know this information.
  90.  
  91. Well, sirs, what do you think?
  92.  
  93. ---
  94. Later,
  95.  
  96. -Don Yacktman
  97. Don_Yacktman@byu.edu